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[ METHOD AND APPARATUS FOR 
EFFICIENTLY RUNNING AN 
EXECUTION IMAGE USING 
VOLATILE AND NON-VOLATILE 

MEMORY} 

Cross Reference to Related Applications 

This patent application claims priority under 35 U.S.C. § 11 9(e) to U.S. Provisional 
Patent Application Serial No. 60/340,61 7, filed October 30, 2001 , for METHOD AND 
APPARATUS FOR EFFICIENTLY RUNNING AN EXECUTION IMAGE USING VOLATILE AND 
NON-VOU\TILE MEMORY, the entirety of which is hereby incorporated by reference. 

Background of Invention 

[0001] The present invention generally relates to a computer system and methods for 
efficiently executing computer programs. 

[0002] A set-top box Is a device that enables a television set to become a user interface 
capable of receiving and decoding digital television broadcasts via phone, cable, the 
Internet, or other means of communication. Set-top boxes are sometimes called 
receivers. As set-top box technology matures and new features are added, the size of 
the execution image of the computer program grows and consequently the demand 
for memory also grows. The modern set-top box requires memory in order to store 
computer programs and other information related to the applications Implemented by 
the set-top box. As the size of the execution image grows, the programming time 
takes longer, including the physical programming time for the non-volatile memory 
and delivery time for the execution image through broadband networks in the case 
when the set-top box allows remote programming of the execution image. In view of 
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the foregoing growth In required memory size, It would be desirable to provide one or 
more techniques which provide for memory storage In set-top boxes capable of 
handling the growing size of execution images which are cost-effective and efficient. 

Summary of Invention 

[0003] In order to achieve the above-mentioned objectives, the present invention 
provides an apparatus and method for efficiently running an execution image 
containing instructions for running a computer program. A non-volatile memory 
stores a compressed version of the execution image. A volatile memory is configured 
to execute the execution image. A computing unit transfers and decompresses the 
compressed version of the execution image from the non-volatile memory to the 
volatile memory where the execution image in non-compressed form can be executed 
efficiently. 

Brief Description of Drawings 

[0004] In order to facilitate a fuller understanding of the present invention, reference is 
now made to the appended drawings. These drawings should not be construed as 
limiting the present Invention, but are intended to be exemplary only. 

[0005] FIG. 1 shows a computer system for executing code according to the present 
invention. 

[0006] FIG. 2 shows a computer system for executing code with a boot/oader according 
to the present invention. 

[0007] FIG. 3 shows a memory map according to the present invention. 
[0008] FIG. 4 shows a method of decompression according to the present invention. 
Detailed Description 

[0009] 

The present invention is directed to set-top box technology. The invention allows 
computer code (an execution image) to be executed faster and more efficiently in a 
set-top box. In FIG. 1 is shown a computer system 1 00 (e.g., a set-top box) of the 
present invention which comprises a volatile memory 1 10 such as dynamic random 
access memory (DRAM) and a non-volatile memory 120 such as a Flash read-only 
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memory (FlashROM). The non-volatile memory 1 20 retains its information even when 
there is no power (such as in a hard disk). The volatile memory 11 0 must have power 
to work but has the advantage of being cheaper than the FlashROM and executing 
more rapidly. The non-volatile memory 120 has a small memory size in comparison to 
the volatile memory 1 1 0. The computer system 100 is configured to receive an 
executable image containing computer code, for example the compressed image 1 25 
from a remote source 50 over a transmission medium 55. The transmission medium 
55 may be a broadband network, a cable system, the Internet, or any other 
communication system capable of transmitting digital data. 

[001 0] The present invention allows a compressed version of the execution image 1 25 to 
be stored in the non-volatile memory 120. Compression reduces the size of the 
execution image allowing it to be stored in a smaller space. Additionally, the 
compressed image 125 could be more rapidly transmitted over the transmission 
medium 55. When it is time to execute the computer program, the execution image 
125 is transferred and decompressed (on the fly) into its executable code 1 1 5 which is 
stored in a portion 1 1 5 of the volatile memory 1 1 0. The volatile memory 1 1 0 can hold 
the larger decompressed version of the execution Image and can execute it more 
rapidly. The computing unit (e.g., a CPU) 1 30 contains a bootloader proqvdm which is 
further described in SECTION A. The bootloader proqxdm resident in the CPU 1 30 is 
responsible for initializing the set-top box and carrying out the decompression 
sequence described herein. 

[001 1] piQ^ 2 shows more details of the computer system 1 00 set out in FIG. 1 . FIG. 3 
shows the details of the memory images for the volatile memory 1 10 and the non- 
volatile memory 1 20. The memory space of the non-volatile memory 1 20 comprises 
an original header (O.H.) 126, a Pioneer header (P.H.) 127, uncompressed code 128, 
and a compressed image 125. The compressed image 1 25 when transferred to the 
volatile memory 1 1 0 expands into the uncompressed execution code 1 1 5 comprising 
a header 1 1 7 and an operation system along with applications 1 1 8. The code 1 28 
comprises (in uncompressed format) the decompression algorithm used to 
decompress the compression image T25. This is advantageous because the 
decompression algorithm of the compressed code 128 may thus be changed without 
changing the software of the computer system 100. Another advantage is that the 
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decompression algorithm may be updated and downloaded from a central location as 
needed without changing the software of each individual set-top box thus facilitating 
maintenance. 

[0012] FIG. 4 shows the decompression process according to the present invention. This 
decompression process allows the executable image to be executed either in the non- 
volatile memory 1 20 or the volatile memory 1 1 0 after copying the execution image 
from the non-volatile memory 1 20. In step 200, the executable image 125 in 
compressed form is initially found stored in the non-volatile memory 1 20. In step 
210, the boot/oacfer checks the code for the pioneer header 127. If there is no pioneer 
header then in step 230 the executable image 125 is copied on the fly to the volatile 
memory 1 1 0. If there is a pioneer header, then at step 220 the code is called and 
subsequently executed from the non-volatile memory 1 20. In step 240, the 
boot/oader} 20 jumps to the start address of the operating system on the volatile 
memory 1 1 0. The decompression algorithm 1 28 is configured to decompress the 
compression code in pieces. In other words, the decompression algorithm (1) 
decompresses a piece of the operating system (OS) image and puts this piece in the 
volatile memory and (2) continues with step (1) until it finishes extracting the whole 
OS image. In step 250, the i&oof/Mflferstarts the operating system. 

[001 3] The foregoing description is believed to adequately describe the overall concepts, 
system implementation and operation of the various aspects of the invention in 
sufficient detail to enable one of ordinary skill in the art to make and practice the 
invention with all of its attendant features, objects and advantages. However, in order 
to facilitate a further more detailed in depth understanding of the inventions and 
additional details in connection with even more specific, commercial implementations 
of various embodiments of the invention, the following further description and 
explanation is given. 

[0014] The following is a more detailed description of the bootloader program. Again, for 
purposes of organization, clarity and convenience of explanation, the additional 
disclosure is set forth in the following section. 

[00 1 5] Sect/on A: Bootloader Program The following is a detailed description of the 
bootloader program. Bootloader for BD 
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[0016] 



Kaz Miyoshi 



[0017] ParkUh 

[001 8] Target CPUBROADCOM BCM71 00 

[0019] Bootloader?xo6\xzt Number:Z03 01 00 0004 01 Version:0.60.071 References 
Author Document SA DHCT code download operation and data structure ver. 1.10 

[0020] PowerTVPIatform HAL API ver. 1 .Oa ^ 

[0021] PowerTVPowerTV Hardware Abstraction Layer API Reference ver 2. 0a2.4. 

[0022] PowerTVConnection Your Set top to an SA Network ver. 1 .ODraft 

-% ElA/CEAPloneerNVM map. xls 

J 

1 [0023] PioneerFlashROMDriver.doc 

Q . . ■ 

[0024] 2 Conventions Used in This DocumentThe following conventions are used: Italic 

"i Represents file and directory names, function names, program variables, names of 

% documents and of chapters in this document, and general emphasis. Represents 

f command names, options, and front panel keys. Constant Width Represents 

I programming language keywords such as int and struct. In examples, it is used to 

show program code, input or output files, and the output from commands and 

program runs. Constant Width Bold Used in examples to show commands or input 

that you enter at the terminal. Constant Width ItalicUsed in examples to show generic 

(variable) portions of a command that you should replace with specific words 

appropriate to your situation. For examples:>log set All info means to type the 

command log, followed by the name of a file. 

[0025] 3 Boot Process at a GlanceThe very initial system startis one of main tasks of the 
Bootloader. The section summarizes the boot process, in 

[0026] 3.1 Board InitializationAfter application of power to the box, the Bootloader fwsx 
takes control of the BD- V3 0 0 0 system. It then does minimal hardware Initialization, 
such as: CPU (and its related, minimal peripheral controller) SDRAM controller System 
caches This is also the stage at which all the LED segments are lit for 750 
milliseconds. This very first step is achieved by careful Assembly coding because no 
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memory is yet available at this stage. 

[0027] 3.2 Primitive Software InltiallzationOnce those initialization done, the Bootloader 
proceeds to the next stage, at which it does software initialization In order to properly 
starta highsoftware language such as C Language. This Is also the stage at which the 
Bootloader \odi6s itself from FlashROM to SDRAM and executes the code out of 
SDRAM. The Bootloader yNdiS originally designed to run on the FlashROM, but we 
observed an occasional MPEGPS sections lost during our Bootloader X^st at PowerTV 
office. The problem persisted, except for running the Bootloader on SDRA.M. Running 
the Bootloader ox\ SDRA.M surely speeds up its Execution, while the only drawback 
would be some extra space on SDRAM which the Bootloader runs.Jho, cause of this 
problem is yet undetermined. 

[0028] 3.3 OS Level Software InitializationWhen the Bootloader r^diches here, it then 

initiates the system software (a kind of OS) initialization. It prepares multienvlronment 
and finally passes control to the Root thread, which is also the Main thread of this 
Bootloader. 

[0029] 3.4 Main Thread startedAt the beginning of the Main thread, it calls HALdrivers' 
initialization methods and has them ready for use. Now. the Bootloader \s full 
functional and ready to start whatever it has to do. The first practical task of the 
Bootloader IS to launch the Menu Console (see Chapter S Menu Console) on\y if asked 
by users. Pressing the MENU Button on the front panel will trigger this Menu Console 
and print the greeting message and a list of menu items to the console via a serial 
port. The Menu Console allows users to download the OS image and the Bootloader 
itself via the very same serial port, control log message output, and so forth in an 
interactive way. When users exit from the Menu Console , or else the Menu Console Is 
just not activated, the Bootloader continues to its subsequent procedure. The 
Bootloaderthen checks to see if any valid OS exists in the FlashROM, and if it Is 
evaluated to good, loads it into SDRAM and execute it unless the OS is disabled by 
of the system parameter stored in NVM or a download request made by the OS is left 
pending. 

[0030] To be precise, the Bootloader performs this process in the following manner. 
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[0031] 1 The Boot/oader checks to see if a valid OS is installed in FlashROI\4. If It finds a 
valid OS, it continues to the next step [2], 

[0032] If it doesn't, it initiates a download process on its own volition and tries to 
download whatever available OS for our boxes [6]. 

[0033] 2.Next, the Boot/oader checks the OS Boot Enabled Flag stored in NVM. If it finds 
the flag disabled, it initiates a download process [6], otherwise continues to the next 
step [3]. 

[0034] 3.Next, the Boot/oader checks to see if there is a download request made by user, 
and if there is, it Initiates a download process and tries to download a newer version 
of OS (see Chapter 4.2 Updates upon user request (case c.)). If there isn't, the 
Boot/oader continues to the next step [4]. 

[0035] 4Then, the Boot/oader checks to see If there is any pending download request 
previously made by the OS installed in the FlashROM. If there is one, the Boot/oader 
initiates a download process based on the Information given by the request [6], 
otherwise continues to the next step [5]. 

[0036] 5.This is the stage at which the Boot/oader loads the OS into SDRAM and execute 
it. The OS in FlashROM may or may not be compressed (see Chapter 9 ComjDressed OS 
download). If it is, the selfOS image will automatically inflate. At the end of loading. 

the Boot/oac/er evaluates CRC to see if loading was successfully done and executes the 
OS unless the CRC Is bad. If this is the case, the Boot/oader \n\t\ates a download 
process [6]. 

[0037] 6.At this stage, the Boot/oader attempts to download an available OS via RF data 
channel. This attempt continues until it compIetes.The Boot/oader \n\\\ reboot the 
system on completion of the download (seeChapter 4 Download Scenario for details of 
download procedure). 

[0038] 

4 Download Scenarioln field, OS download takes place in the following 
causes.a.When the Boot/oader can't find a valid OS in FlashROM on application of 
power to the box.b.When OS Boot Enabled Flag is set to disabled.c.When user asks for 
a download.d.When the OS issues a download request to the Boot/oader on runThe 
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following chapter explains each download action corresponding to each cause listed 
above. 

[0039] 4.1 Selfdownload (case a. and b.)Under these conditions, the Boot/oader consider 
that there's no valid OS to start in FlashROM. Hence, it initiates a download process of 
its own volition and takes whatever available version of OS for our boxes at that time. 
It hunts for the frequencies until it gets a CVT (see DHCT code download operation 
and data structure ver.l .1 0 as regards its format in detail) out of MPEG private 
section. Once it gets a CVT and finds a matched record to our particular type of box in 
the CVT, then it in turn initiates DSMdownload based on the specific information given 
by the CVT record . This process continues until the download completes. On 
completion of download, the Boot/oader burns the downloaded image into FlashROM 
and reboots the system. 

[0040] 4.2 Updates upon user request (case c.)Thi5 specific download is initiated by users 
(such as service operators) and triggered off by pressing the front panel VOLkey down 
upon application of power to the box and held pressed until the front panel LED 
displays hnnn to indicate the hunt for the frequencies has initiated. However, this 
procedure does NOT forcibly update the OS image, but It does if and only if any newer 
version of OS is available for our boxes (to be precise, any different version than the 
current one you box has). The Boot/oader keeps searching for the newer OS until it 
finds a new version of OS and then completes a download or else next power cycle. 

[0041] 

4.3 Updates upon OS request (case d.)This is the download that should normally 
take place in field. In this scenario, the OS is in charge of obtaining CVT through either 
MPEG private section or QPSK Pass Through Message and passing it to the Boot/oader 
because, needless to say, the Boot/oader \s not running once it launches the OS.Since 
the OS has no intelligence to interpret CVT, it passes CVT to the Boot/oaderXhrough 
HAL/bldr interface in order to query availability of newer versions. On the other hand, 
the Boot/oader hdislcaWy has no right to initiate a download even if a newer version of 
OS is available. It notifies the OS of the availability of download and leaves the OS 
when to initiate a download unless CVT designates either Emergency download or 
forced dowvnioad . If this is the case, the Boot/oader start an immediate 
emergency download without OS interaction. In either case where a download is 
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needed, a download request is once saved into NVM and resets and reboots the 
system into the Bootloader. On the next run of the Bootloader, the request saved in 
NVM contains a frequency number at which the OS image is broadcasted. Thus, the 
Bootloader do^s not need to hunt around the frequencies to get the initial download 
information, i.e.. a CVT record, rather directly tunes to the specified channel and 
initiates DSMdownload immediately. This process continues until this specific 
download request completes. On completion of download, the Bootloader burns the 
downloaded image into FlashROM and reboots the system. 

[0042] 5 Menu ConsoleThe Menu Console was designed to facilitate the manufacturing, 
the field service, or else troubleshooting. The Menu Console prints to a DTE (Data 
Terminal Equipment, or terminal), such as HyperTerminal, via serial communication. 
Use a DTE(straightcable to connect a box with a terminal. 

[0043] 5.1 Terminal Configurationln order for the Bootloaderto communicate properly 
with the terminal, the following configuration is required for the 
terminal. ParametersValuesBaud ratel 15200 [bps]Data bitsSParltyNoheStop bitsl Flow 
controlNone 

[0044] 5.2 Menu Console Invocation and Password Authentication.The Menu Console is 
invoked when the front panel MENNU key Is pressed down upon application of power 
to the box and held pressed down until the front panel LED starts displaying - - and - 
- by turns, which lasts for ten seconds and during which the Bootloader \s waiting for 
user password to be provided from a terminal. Note that neither prompt nor any 
navigation message appears in the terminal until you supply a good password. This is 
to avoid possible troubles in filed, where IRmay be connected to the serial port.Now, 
you must enter either Public Password or Unique Password to activate the 
MenuConsole. If you don't supply any good password before timeout, the Bootloader 
returns to the normal boot sequence.When you enter the Public Password, you will see 
the following Standard Menu display at the terminal screen. 

[0045] VoyagerB Bootloader U^xwx Console 

[0046] P/N:Z03 01 00 0004 01 

[0047] Ver:0.60.05, built: 18:03:57. March 13 2001 
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[0048] Select item below and hit return 



[0049] Menu Console 



[0050] 



Select a number below 



[005 1 ] 1 : PowerTV OS download 



[0052] 2: PowerTV OS download w/ forced FLASHROM programming 



[0053] 3: Boot/oader Update 



[0054] 



4: Disable CS boot 



;f [0055] 5: Set Download Carrier 



J [0056] 
^: [0057] 



6: Boot From FlashROM 



7: Exit Menu Console 



;;s [0058] 

Ml 



If you enter the Unique Password, you will see an extra menu item 8: Expert Menu 
in addition to the Standard Menu items. 



[0059] VoyagerB Boot/oac/er Menu Console 

[0060] P/N: Z03 01 00 0004 01 

[0061] Ver: 0.60.05, built: 18:03:57, Mar 13 2001 



[0062] 



Select Item below and hit return 



[0063] Menu Console 



[0064] Select a number below 



[0065] 1 : PowerTV OS download 



[0066] 2: PowerTV OS download w/forced FLASHROM programming 



[0067] 3: Boot/oader Update 



[0068] 



4: Disable CS boot 
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[0069] 



5: Set Download Carrier 



[0070] 



6: Boot From FlashROM 



[0071] 



7: Exit Menu Console 



[0072] 



8: Expert Menu 



[0073] 



The next section explains each menu item in detail 



[0074] 5.3 Standard Menu functions 

[0075] 5.3.1 1 : PowerTV OS downloadWhile the Bootloader \s designed to download the 
OS image via inchannel, it is also capable of downloading via serial line. Nevertheless 
It takes several minutes to download the big OS Image, the serial download comes in 
handy because no special equipment other than a terminal is required. The terminal 
must be capable of 1 K-Xmodem protocol to send a file, but most of the recent 
terminals should be OK.When you select the function 1 at the Menu Console, the 
following message appears and indicates that the Bootloader \s waiting for the OS 
image to be transferred via the very same communication port. You can now send the 
image using 1 K-Xmodem protocol. Note that you have no control of the terminal once 
file transfer Is initiated although canceling file transfer or any other errors during the 
download procedure will return control to you. >1 Download via Serai, use (1 K) 
Xmodem protocolHit ESC to cancel download anytimeCCCThe OS image sent through 
this function has a special format and is called SBL file (see Appendix A. 
Terminologies).During this specific function, the Boot/oacfer accepts the OS image only 
addressed to either FlashROM: Ox 1 fOSOOOO or DRAM: 0x00080000 (Both addresses 
described in physical address. See Chapter 10 Memory Map), which information is 
given by the SBL header (see Appendix C. The Data Structure for Serial Download). On 
completion of the file transfer, the Boot/oacfer programs the image into FlashROM and 
reboots the box if the image address designates FlashROM. If the image address 
designates DRAM, the Boot/oacfer simply execute the Image that has just been 
downloaded. 

[0076] 5 3 2 2: PowerTV OS download w/ forced FUVSHROM programmingThis is one of 
old functions and may be removed in the future. Its function is analogous to PowerTV 
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OS download described above except that it always programs the OS image even if 
DRAM address is specified in the SBL header. While this function seems redundant, it 
may be useful because we don't need prepare separate files for download into DRAM 
and FlashROM respectively. 

[0077] 5.3.3 3: Boot/oader l}pdaXeTh'\s function serves literally to update the Bootloader. 
On completion of the file transfer, the Boot/oader always programs FlashROM in order 
to update itself with newer version. The box will reboot when FlashROM programming 
completes. No content in FlashROM except for the Boot/oader mdige should be 
changed by this function. Warning: Do NOT unplug the power cable while FlashROM . 
I programming is taking place, especially for the Boot/oader update. Such disturbance 

Q will cause FlashROM programming failure and then the system will be no longer 

operational. There"s no remedy to fix this problem once it happens. 

p [0078] 5.3.4 4: Enable OS bootThis funaion is mainly used at the manufacturing stage, 
III where each box is shipped with OS boot disabled. In terms of the Bootloader, 

\ disabling OS boot is analogous to erasing the OS image that resides in FlashROM. 

Ul Thus, if this flag is set disabled, the BootloadermW attempt to download whatever the 

1^1 OS image that is available via RF cable. The Bootloader set this flag enabled 

whenever it completes an OS image download so that the OS will start up from then 

fy. ; 

on. There's no chance for \he Bootloader to set this flag disabled. It is done only 
through this function. 

[0079] 5.3.5 5: Set Download CarrierThis function allows you to specif/ the first digital 

frequency and its type of modulation from which the Bootloader \n\\\ start the hunt for 
the frequencies.The BootloadermW start the hunt from #80/QAM64 by default (see 
Appendix D^or details of the hunt algorithm.) 

[0080] >5 

[0081] Type: frequency (in Hz) [1(QAM256) I 0(QAM64) ] 
[0082] FREQ>61 5000000 0 

[0083] 5.3.6 6: Boot From FlashROM When you select this function, the box simply 
reboots. 
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[0084] 5.3.7 7: Exit Menu Console When you select this function, the Menu Console ends 
and the Boot/oader continues its operation. 

[0085] 5.4. Expert Menu functions: 

[0086] 5.4.1 8: Expert MenuWhen you select this function, the following sub menu will 
appear. Some of these functions are designed solely for software debugging purpose 
and may be removed in the future. 

[0087] Expert Menu Select a number below 

[0088] 1 : RF MAC address programming 

[0089] 2:Ethernet MAC address programming 



[0090] 3: Serial Number programming 



Ul [0091] 

i 

% [0092] 



:;3 [0093] 

: y 

3 [0094] 

: : 3 

[0095] 
[0096] 



4: Phal Download 
5: Command Shell 
6: NVM Test 
7: FlashROM Test 
8: Tuner Test 
9: Mpegps Test 



[0097] 1 0: Exit this Sub Menu, 

[0098] 5.4.2 1 : RF MAC address programming This function allows you to set a RF I^AC 
Address that is saved in NVM located on the motherboard. When the Bootloader 
programs a new RF MAC Address, it also updates CRC of the RF MAC Address, the 
secondary RF MAC Address, and CRC of the Pioneer i-lardware Parameter Block (see 
Chapter 1 0.3 NVM.)Current RF MAC Address 00:eO:36:01 :23:45 Hit return to proceed 
"q" to exitMACPROC>00:eO:36:29:b5:72New RF MAC Address 00:eO:36:29:b5:?2Hit 
return to proceed "q" to exit(l ) MAC programming successfully completed 



[0099] 



5.4.3 2: Ethernet MAC address programming This function allows you to set an 
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Ethernet MAC Address that is saved in NVM located on the daughter card. 

[01 00] 5.4.4 3: Serial Number programming Current S/N: PMUKFFOOOHit return to 

proceed "q* to exitSNPROG> PMUKFF0E3 New S/N: PMUKFF0E3Hlt return to proceed 
to exitd) Serial Number programming successfully completed 

[0101] 5.4.5 4: Phal Download 

[01 02] TEXT 

[01 03] 5.4.6 5: Command Shell 

[0104] TEXT 

«3 [0105] 5.4.76: NVM Test 

S 

% [0106] TEXT 

a [01 07] 5.4.77: FlashROM Test 

I [0108] TEXT 

5 [0109] 5.4.88: Tuner Test 

1J [0110] TEXT 

[01 1 1] 5.4.1 0 9: Mpegps Test 

[0112] TEXT 

[0113] 5.4.1110: Exit this sum Menu 

[0114] TEXT 

[0115] 5.5 Implicit Menus 

[0116] TEXT 



[0117] 



5.5.1 RF MAC Address CorrectionWhen the BoothaderTmds both the Primary RF 
MAC Address and the Secondary RF MACAddress are corrupted due to bad CRC, you 
will see EP02 display on the front panel LED, under which the Boot/oacfer halts its 
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normal operation. To remedy this condition, there's a menu that is activated by 
pressing MENU key on the front panel (no power cycling required), which should 
display the following message on your terminal. It dumps the content of NVM for the 
survey in the first place. Next comes a minimal menu that only allows you to 
reprogram a new RF MAC Address. IMPORTANT: You should be ready to save this log 
for further investigation. 



NVM Read/Wrlre Tesc 

cmd: dump in hex 
offset: 0 
len: 256 

0000: 01 ff Ob b8 00 Oa 50 4d 55 4b 46 46 30 45 33 ba 
0x10; 00 01 ff ff ff ff ff ff 00 eO 36 29 bS 72 67 00 
0X20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
0x30: ff ff ff ff 09 14 Id ff ff ff ff ff ff ff ff ff 
0x40: ff ff ff ff ff ff 19 ff 30 SO ff ff 10 00 00 00 



U1 [0118] 




ff ff tz II 

** *"* ff ff ff 

ff ff ff ff ff 

^f ZZ f f f f f f 
*- *f ff ff ff 
ff ff ff tt ff 
'f ff ff ff ff 
ff ff ff £f ff 
01 fad CO 00 eO 
00 00 00 00 OC 
DO ff ff 80 QC 



f f 

JSC fif 

" f f 

f f f f 

f f f f 

f f f f 

ff ff 

35 2S 

00 00 

o: aS 



[0119] 



Vovager3 Boorlcader Menu Console •♦♦•»*• 
2ldr version: 0.60. 04-s, built: 11:18:19, Feb 21 2001 
Select Item below and hit return 

R? MAC address correction * 

Select a number below 

1: Rr MAC address programming 

2: Boot From FlashH^ 



5.5.2 Serial Number Correction 



[0120] 



When the Bootloader f\nds the Hardware Serial Number is corrupted due to bad 
checksum, you will see EP03 display on the front panel LED, under which the 
Bootloaderhaks its normal operation. To remedy this condition, there's a menu that is 
activated by pressing MENU key on the front panel (no power cycling required), which 
should display the following message on your terminal. It dumps the content of NVM 
for the survey in the first place. Next comes a minimal menu that only allows you to 
reprogram a new Serial Number. IMPORTANT: You should be ready to save this log for 
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further investigation. 



[0121] 



m 



W [0123] 
S [0124] 
m [0125] 
[01 26] 
[01 27] 
[0128] 
[0129] 
[01 30] 
[0131] 



SVH Sead/Hrlce Tesr 

cmd: dtffiip in hex 
of£sec: 0 
len: 2S6 



0000: 


01 


ff 


Ob 


be 


00 


Oa 


50 


4d 


55 


4b 


46 


4o 


30 


45 


33 


00 


0X10: 


00 


01 




ff 


ff 


ff 




f f 


00 


eO 


35 


29 


bS 


72 


67 


50 


0x20: 


ff 


ff 




ff 


ff 


£ C 


ff 




r jr 


f f 


f f 




f f 


ff 


ff 


ff 


0X30: 


ff 


ff 


ff 


ff 


09 


14 


Id 


ff 


ff 


ff 


ff 




ff 


ff 


ff 


ff 


0x40: 




ff 


ff 


ff 


ff 


ff 


IS 


ff 


30 


80 






10 


00 


00 


00 


0X50: 


6b 


06 


OX 


ff 


«« 


ff 


f f 


ff 


f f 








f f 


ff 


ff 


ff 


0x60: 


ff 


ff 




ff 


ff 


ff 






ff 


ff 




f f 




ff 




ff 


0x70; 


f f 


ff 


ff 


ff 


ff 


ff 


f f 


f f 


ff 


ff 


ff 


ff 


f f 


r£ 


ff 


ff 


0X80: 


ff 


ff 


ff 


ff 


ff 


ff 


ff 




f f 


ff 


ff 


f f 


ff 


ff 




ff 


0x90 : 


ff 


ff 


ff 


ff 


ff 


«c 


ff 


ff 


ff 




ff 


ff 


ff 


ff 


ff 


ff 


OxaO: 


ff 


ff 


ff 




ff 


ff 


ff 


ff 


ff 


ff 


ff 


ff 


ff 


ff 


ff 


ff 


OxbO: 


ff 




ff 


ff 


ff 


ff 


ff 




ff 


ff 


ff 


ff 


ff 


ff 


ff 


ff 


OxcO: 


ff 


ff 


ff 


f f 


ff 


ff 


ff 


ff 


ff 


ff 


ff 


ff 


ff 


ff 


ff 


f f 


OxdO: 


ff 


ff 




ff 




ff 


ff 


ff 


05 


01 


bd 


00 


00 


eO 


36 


29 


OxeO: 


b5 


72 


67 


50 


00 


00 


04 


fb 


00 


00 


00 


00 


00 


00 


00 


00 


OxfO: 


00 


00 


00 


00 


00 


00 


ff 


ff 


00 


00 


ff 




80 


00 


01 


a5 



i [0122] 6 Hardware Error detection 



6.1.1 SDRAMTBD 

6.1.2 FlashROM 

The following, FlashROM devices are currently supported. 
Intel 

28F640J3A, 28F128J3A 
ST (TBD) 
M58LW064 
7 LED Display 
7.1 POWER LED 



[01 32] The POWER LED blinks every 400 milliseconds as l<eepindicator independently of 
any Boot/oacfer status while the Boot/oader is in control of the system. Note that it 
stop blinking, while the Boot/oader \s performing a critical operations. 



[01 33] 



7.2 Dot LED, Message and Bypass 
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[01 34] During the hunt for the frequencies (see Appendix D J, the front panel LED 
Indicates the following status. 

[0135] Message dot LED: 

[01 36] Off: QAM64 On: QAM256 

[0137] Bypass dot LED: 

[01 38] Off: Standard QAM frequency On: HRC QAM frequency 

[01 39] 7.3 7-Segment LED 

[0140] 7.3.1 Status of boot process 

[0141] LED Description 

[01 42] Turn off Initial status 

[01 43] 8888 All LED segments (including dots) are lit upon every application of power to 
the box 

[01 44] - - They are by turns displayed every one second indicating the 

[01 45] - - Bootloader is waiting for user to enter a password 

[01 46] MENU Indicates the Menu Console is up and running 

[01 47] Chck Indicates OS validation is going on 

[0148] Load Loading the PowerTV OS into memory 

[01 49] hnnn Indicates the hunt for the frequencies is going on, nnn designates an EIA 
#channel 

[01 50] Lock Indicates (almost instantly) the tuner has locked to a frequency 

[01 51] dLnn Indicates the progress of the RF download progress in nn[%] 

[01 52] FEnn Indicates progress of erasing FlashROM sector(s) in nn[%] 

[01 53] FWnn Indicates the progress of programming FlashROM sectors in nn[%] 
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[01 54] do Waiting for the Xmodem download via serial 

[0155] dl Xmodem download initiated 

[01 56] d2 Download data evaluated to good 

[0157] 7.3.2 Error Status 

[0158] LED Description 

[01 59] EPOO Fatal errors not yet assigned specific numbers 

[0160] EPOl SDRAM R/W error 

g [01 61] EP02 RF MAC CRC error (in NVM) See Chapter 5.5.1 RF MAC Address Correction 

i H [01 62] EP03 Serial number checksum error (in NVM) See Chapter 5.5.2 Serial Number 
Correction 

}^ [01 63] Exnn CPU exception number nn that is irrecoverable 

Q [01 64] TBD Unsupported FlashROM device (E-Signature Error) 

\U 

^ [0165] LED Description 

[0166] E-01 Generic Serial download Error 

[01 67] E-02 Invalid length error: the length field in SBL header does not indicate a 
multiple of 4 

[01 68] E-03 Out of range error: the image does not fall into the proper memory space 
( The start address and the length information In SBL header is not correct) 

[01 69] E-04 Data length error: the total length of data actually received via xmodem 
download is less than the length specified in SBL header 

[01 70] E-05 Checksum error: SBL header checksum invalid 

[01 71] E-06 Maker not found error: Romlnfo Block supposed to be following the SBL 
header does not contain the valid Marker BASEBOOT 
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[01 72] E-07 CRC Error: GRC in Romlnfo Block does not match 

[01 73] E-08 Start address error in SBL header 

[01 74] E-09 FlashROM sectors" uniocic error 

[01 75] E-1 0 FlashROM sectors" lock error 

[01 76] LED Description 

[01 77] E-20 Generic Xmodem Error during serial download 

[0178] E-21 Xmodem download canceled errorLEDDescriptlori 

[01 79] E-30 FlashROM programming error ( Bootloader update failure) 

[01 80] E-31 Generic FlashROM programming error 

[01 81] E-32 Bad address error: The given address is out of range 

[01 82] E-33 Bad sector number error: The given sector number is out of range 

[01 83] E-34 Bad device error: Low voltage detected 

[01 84] E-35 Time out error: Time out occurred during FlashROM programming 

[01 85] E-36 Protected error: The attempt to write or erase a FlashROM sector failed 
because the sector is protected 

[01 86] E-37 Command sequence error: indicates potential FlashROM driver error 

[01 87] E-38 Erase error: Erasing a sector failed, possible device error 

[01 88] E-39 Write error: Writing into a sector failed, possible device error. 

[01 89] 8 Platform HAL API Support 

[01 90] 

The Bootloader supports a set of functions as known as PHAL API which is utilized 
by PowerTV OS on run(see Platform HALAPI ver. 1 .Oa2 for details). PowerTV OS 
accesses those functions through a table of pointers to functions which structure is 
called Phal SimpleDownLoadAPIpointers.An instance of this structure is placed at 
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VMA:0x80000800, and that address information is notified to PowerTV OS on run 
(Hence, it does not matter where to locate the structure.) In addition to PHAL API, we 
have Pioneer proprietary API, which can be utilized by HAL drivers on runThe structure 
Bldr_Anchor is currently defined as follows and mav be extended in the future, 

[0191] Typedef struct Bldr_Anchor{ 

[0192] r^JvmdShdw pNvmdShdw; 

[01 93] Boolean (*getCvtRecord) ( Stram.Buffer *pStrmBuf,C\/T_!NFO *pCvtlnfo,Boolean 
bIgnoreimageld.Boolean bCalledByOS); 

[01 94] uil 6 (*getCrc1 6) (ui8 *pData, ui32 length, uil 6 crc); 

[01 95] 132 (*flshGetBlkNum) (ui32 addr); 

[01 96] ui32 (*flshCetBlkAddr) (132 IBIkNum); 

[01 97] Boolean (*flshBlkLocked) (132 iBIkNum); 

[01 98] i32 (*flshBlkLock) (i32 iBIkNum ,Boolean bLock); 

[0199] 132 (*flshBlkErase) (132 IBIkNum); 

[0200] 132 (*flshWrite) (uil 6 *dst, uil 6 *src, ui32 hien); 

[0201] void (*flshSetWriteLED) (Boolean bEnable); 

[0202] i32 (*flshCetWriteProgress) (void)Bldr_Callout)*callouts; 

[0203] } Blfr_Anchor; 

[0204] Where 

[0205] pNvmdShdw is a pointer to the Structure NvmdShdw. which is solely used by 
HAL/bldr driver and its description is beyond the scope of this document. 

[0206] getCVTRecord is a pointer to a function, which is solely used by HAL/bldr driver 
and its description is beyond the scope of this document. 

[0207] 

getCrcl 6 is a pointer to the function to calculate CRCl 6 described in Chapter 1 0.3 
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NVM. This function is available for the runimage and multithread-safe. pData is a 
pointer to an array of data to process, length is the number of data bytes to process, 
crc: is either previous return value of this function or Oxf f f f as initial value. 

[0208] The members from fIshGetBlkNum through fIshCetWriteProgress are all pointers 
to the FlashROM driver functions. They are available for the run-time image but NOT 
multithreadHence, care must be taken by the callers. See FlashROM Driver, doc for 
detailed description of those functions. 

[0209] callouts is a pointer to the structure BIdr. Callout. The structure is designed to 
holds a list of pointers to callout functions that are once initialized to NULL by the 
% Soot/oacfer and then assigned values on runCiven a value, the Boot/oadermW execute 

=33 it on a specific time accordingly. The structure is currently defined as follows and may 

m 

be extended in the future. 
y1 [0210] typedef struct Bldr.Callout{ 



.phaLReset () to reset and reboot the system. 

[021 5] Warning: Any API (callable from the runimage) must be carefully designed so that 
it won't use any system calls of the Bootloaderox standard library. As regards the 
standard library, it would be OK to use some of functions in it, but any function that 
potentially uses memory allocator of the Bootloadermay have bad side effect on the 
runOS image because the current memory allocator does not sense the presence of 
the OS image and uses memory as much as possible if needed 

[02 1 6] A pointer to a Bldr^Anchor structure is located right after a 
PhaLSimpleDownLoadAPIpointers structure as follows 

[0217] typedef struct PhaLExAPIpolnters{ 




void(*resetco) (void); 



[0213] 



Where, 



[0214] 



resetco is a pointer to the userfunction, which is called when the OScalls 
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UJ 



[0218] PhaLSimpleDownLoadAPIpointers std; 
[0219] Ui32 anchor; 

[0220] PhaLExAPIpointers;Where. anchor holds a pointer to a BldrJVnchor structure and 
allows the runimage to locate the structure as seen in the following 
example.BldrJVhcor *panchor = )bldr_Anchor *) (((PhaLExAPIpointers*) 0x80000800) 
PAnchor = foo; 

[022 1 ] 9 Compressed OS download 

[0222] The OS image is compressed, and downloaded in the FlashROM. During system 
booting the compressed OS is unzipped by unzip utility, and loaded in the DRAM 
memory for execution. 

[0223] 9.1 Compression 

[0224] The original OS image consists of ROM Info Block and Power TV OS, and is 
compressed by free GNU gzip.exe (version 1.2.4) utility during build process. 

[0225] The compressed image consists of gzip header (1 5 bytes) starting with magic 

number (0x1 fSb), compressed data, CRC32 check sum (4 bytes), and the size of the 
original data (4bytes). 

[0226] 9.2 PrepareForZip 

[0227] PrepareForZip prepares the compressed OS for the Bootloaderto execute unzip 
operation at system booting. First it makes the compressed OS image acceptable by 
DNCS by adding a Dummy ROM Info Block . And it adds another block of data called 
Pioneer Header that contains information about unzip operation for the Bootloaden 
Finally it appends unzip executable binary. The output image of the PrepareForZip 
consists of the following blocks of layer in order. 

[0228] Dummy ROM Info Block 

[0229] Pioneer Header 

[0230] Unzip executable 
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[0231] 



Compressed OS 



[0232] Prepare,ForZip utility program expects three input files, the original OS binary 
image file (ptvrom.bin), unzip utility file (punzip.bin) and compressed OS binary file 
(ptvrom.gz). Also it needs the start address of the compressed image downloaded in 
the FlashROM and the destination address of the unzipped OS in the DRAM memory. 



3 



10233] The Dummy ROM Info Block contains a copy of the original ROM Info Block with 
three elements modified, the Start Address, ImageLength and CRC. The new 
StartAddress points to the beginning of the Pioneer Header, which contains the 
address of the ^/7z/p function. The ImageLength and CRC are updated for the newly 
created output image. 

[0234] The Pioneer Header contains information regarding unzip operation for the 

Boot/oacfer After checking integrity of the compressed OS image in the FlashROM, the 
Boot/oader executes the unzip operation by jumping to the address stored in the 
Pioneer Header. 



1J 



[0235] The Pioneer Header consists of the following data structure, 
[0236] typedef struct PIONEER.HEADER { 



[0237] 



unsigned int unzipFuncPtr; 



[0238] 



unsigned int unzipFrom; 



[0239] 



unsigned int unzipTo; 



[0240] 



unsigned int unzipLength; 



[0241] unsigned int flag; 



[0242] char marker[8]; 



[0243] 



unsigned int reservedO 



[0244] unsigned int reserved] [8]; 



[0245] 



1PIONEER.HEADER; 
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[0246] The unzipFuncPtr contains the address of the unzip function. The unzipFrom 
contains the start address of the compressed OS image in the FlashROM to be 
unzipped. The unzipTo contains the destination address for the unzipped OS to reside 
in the DRAM memory. The unzipLength is the total size of the compressed OS to be 
unzipped. The flag indicates whether the FlashROM image is compressed or not. The 
marker is "ZIPPEDOS", and used by Bootloader^ox identification of the image. The rest 
of the reserved space is for future expansion. 

[0247] The PrepareForZip utility, PrepareForZip.exe, is built by Microsoft Visual C++ 
environment under c:\projects\utils\prepareforzip directory. 

[0248] 9.3 Unzip utility 

ifl [0249] The unzip utility, punzip. bin, is developed under c: \projects\voyager3 \unzip 
<j| directory, and built by CYGNUS tools. One thing to note is that unzip function uses 

If last 1 M byte of DRAM space, which is free during system booting, for its data section 

and heap area. The entry function of the unzip utility is also the function that Is called 
by Bootloaderto execute unzip operation. This function takes the arguments from the 
caller. Those are the address of the compressed OS image in the FlashROM as a 
source, the address of destination in the DRAM memory for the unzipped image, and 
the size of the source image. The unzip function returns zero to the caller for success. 



m 



[0250] The unzip algorithm is adopted from the GNU gzip utility, and modified for our 
project. 

[0251] 10 Memory Map 

[0252] The following memory map Is described inPMA (Physical MemoryAddress.) To 
interpret physical address into the program address space, soVMA (Virtual Memory 
Address), apply the following formulas. 

[0253] For cached memory space: 

[0254] VMA = PMA I OxaOOOOOOO 

[0255] For nonmemory space: 

[02 56] VMA = PMA I 0x80000000 
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[0257] 10. 1 FlashROM 
[0258] Address Description 

[0259] 0x1 fOOOOOO ^of/oaofe/- code space (Write Protected)Description 
[0260] (512KB) 

[0261 ] 0x1 f080000 Storage for OS & Resident Applications 
[0262] (7.5IVIB) 
[0263] 10.2SDRAM 

Address Description 

0x00000000 Bootloader code/data space 
(512KB) 

j jl [0267] 0x00080000 OS & Resident Applications 

5 [0268] (15.5MB) 

s^h ■ ■ 

•\\\& 

rU [0269] 10.3 NVM 

[0270] The usage of Pioneer NVI^ space is left to NVM map.xis.ln this chapter, we focus 
on how to calculate values for CRC fields, such askNvm_HWParamBlk_CRCl 6 and 
kNvm_RFMAC_CRC16, and a checksumfieldkNvm.PiHWSerialNumberChecksum. 

[0271] CRC 16: 

CCITT CRC 1 6, Polynomial x^^ + x^^ + x^ + 1, Seed OxfFff 

One's complement of the generated CRC is placed to the CRC field with themost 
significant byte swapped with the least significant byte as seen below. 

#define APPEND(pbytes, nbytes) \ 

{\ 



m 



[0264] 
[0265] 
[0266] 



[0272] 
[0273] 

[0274] 
[0275] 
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[0276] unsigned short tmp = \ 

[0277] crcl 6 (pbytes, nbytes. Oxffff) ^oxffff; \ 

[02 78] (pbytes) [ (nbytes) + 0 ] = (tm p > > 0) & Oxff; \ 

[0279] (pbytes) [ (nbytes) + 1 ] = (tm» 8) & Oxff; \ 

[0280] } 

[0281 ] Checksum: Retrieved by the following formula. 

[02 82] Oxff A byte[ 0 ] A byte [ n A byte [ 2 ] A byte[n) 

C3 [0283] 1 1 Appendixes 

[0284] A. Terminologies 

iji [0285] SBL header: 

m ■ ' 

[0286] A commonly used name for Phal_SimpleDownloadHeader. The file attached with 

U1 this header is often called SBL file. OS Boot Enabled Flag ; 

;J| [0287] The most significant bit of kBldr_SysFlags stored in NVM. This bit is set to 1 (one) 

P!J to enable OS. See NVMmap.xls for details of kBldr.SvsFlags.CVT: 

[0288] A short for Code Version Table. See DHCT code download operation and data 
structure ver.l .10 for details. 

[0289] CVT record: 

[0290] Contains download information, such as a frequency at which the OS image is 
conveyed, that corresponds to a specific type of box 

[0291 ] Pioneer Hardware Parameter Block 

[0292] Read-only parameters stored in NVM, which is initialized at the factory for each 
box. This block ranges from kNvm_Pi Cookie through kNvm.PiCRCl 6^Lo (see NVM 
map. xls). 

[0293] TEXT 
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[0294] 



B. &?of/oai/er Versions and Hardware Parameters 



[0295] 



Item Description 



[0296] 



BootloaderR<s\i\s\ox\ 0.1 0.nn support the Platform API only 



[0297] 



O.eo.nn 1 SQA release 



[0298] 



0.70.nn 2 SQA release 



[0299] O.SO.nn SA certification release 

[0300] 0.90.nn TP release 

[0301] 1 .OO.nn PP/MP release 

[0302] Manufacturers ID OxOOe036 

[0303] Manufacturers Model 1300 (decimal) 

[0304] Manufacturers Revision 1 0 (decimal) 

[0305] Hardware ID 1 (decimal) 

[0306] C. Tlie Data Structure for Serial Download 

[0307] typedef struct PhaLSimpleDownLoadHeader 

[0308] ui32 checicsum; 

[0309] ui32 startAddress; 

[0310] ui32 datalength; 

[0311] ui 32 reserved; 

[0312] } PhaLSimpleDownLoadHeader; 

[0313] Where, 

[03 1 4] checksum is XOR of all the following fields and the binary data. 
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[0315] 



startAddress designates the address to place the data into memory. 



[0316] 



datalength designates the length of the binary data in bytes, excluding this 



header. 



[0317] 



reserved is reserved for future expansion. 



[031 8] D. The Hunt for the Frequency 

[03 1 9] Although the Bootloader retrieves CVT from init does not have any means to get a 
channel allocation map that should describe the valid channel allocations. Hence, it 
needs to search each possible digital carrier for an available data channel, which we 
call the hunt for the frequencies. During the hunt for the frequencies, the Bootloader 
searches each possible digital carrier in the following manner until it gets CVT. The 
following each step continues next unless the Bootloader succ^ssMVf gets the tuner 
locked within 2 seconds and retrieves CVT within the next 3 seconds. Suppose N 
indicates an EIA channel number: 

[0320] a.Tune to the Standard QAM frequency corresponds to N with QAM64, 

[0321] b.Tune to the Standard QAM frequency corresponds to N with QAM256. 

[0322] c.Tune to the HRC QAM frequency corresponds to N with QAM64. 

[0323] d.Tune to the HRC QAM frequency corresponds to N with QAM256, 

[0324] e.lncrement N and repeat a) through e). If N reaches to the maximum channel that 
the tuner can handle, and then it is reset to 2. 

[0325] QAM64: Symbol Rate 5,0569.00 K symbol/sec 

[0326] QAM256: Symbol Rate 5,3606.50 K symbol/sec 

[0327] E. DNCS Versions 

[0328] DNCS revision 1 .4 or later 

[0329] The present invention is not to be limited in scope by the specific embodiments 
described herein. Indeed, various modifications of the present invention, in addition 
those described herein, will be apparent to those of si<ill in the art from the foregoing 
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description and accompanying drawings. Tlius, such modifications are intended to fall 
witliin tlie scope of tlie appended claims. 



: s 




iff 
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